-
Notifications
You must be signed in to change notification settings - Fork 546
Rewrite core.relax_integer_vars
transformation
#3586
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…o into modernize-relax-integer-vars
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Accidentally hit merge when I meant to update the branch from main. This is fine, with three small comments (none of which would have prevented merging).
for b in block.component_data_objects(Block, active=None, descend_into=True): | ||
if not b.active: | ||
if config.transform_deactivated_blocks: | ||
deprecation_warning( | ||
"The `transform_deactivated_blocks` arguments is deprecated. " | ||
"Either specify deactivated Blocks as targets to activate them " | ||
"if transforming them is the desired behavior.", | ||
version='6.9.3.dev0', | ||
) | ||
else: | ||
continue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some questions:
- Why descend only over
Block
when you acceptBlock
andDisjunct
as targets? Should this becomponent_data_objects(SubclassOf(Block), ...
? - Why test for
active
inside the loop? Wouldn't it be easier toactive = None if config.transform_deactivated_blocks else True
? Is the idea to only issue the deprecation warning if model actually had a deactivated block?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, all of this is to make sure we only issue the deprecation warning if the model actually has a deactivated block that we're transforming. When we remove the argument, all this complexity can go away and we can just do what you suggest above. I just didn't want to be loud in all the cases where this is fine because (annoyingly) the default value for transform_deactivated_blocks
is True
. So without this mess I would just be raising deprecation warnings when the user didn't actually do anything--they probably don't know the option exists.
Fixes # .
Summary/Motivation:
This rewrites the
core.relax_integer_vars
transformation, modernizing it to our more recent transformation conventions. In particular, it:undo
argument in favor of implementingreverse
according to the design we introduced in Adding (reversible)gdp.transform_current_disjunctive_logic
transformation #2809.targets
argumentcomponent_data_objects(Var)
Changes proposed in this PR:
core.relax_integer_vars
transformationVarCollector
enum to distinguish getting Vars from active expressions vs. usingcomponent_data_objects(Var)
. Naming suggestions are welcome here...Legal Acknowledgement
By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution: